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L REAL PARTY IN INTEREST 

Christian R. Thomas, Narasimha R. Edala and Joel 1. Marcey, the parties named in the 
caption, transferred their rights to that which is disclosed in the subject application through an 
assignment recorded on March 29, 2001 (01 1676/0324) in the patent application to Intel 
Corporation, of Santa Clara, California. Thus, as the owner at the time the brief is being filed, Intel 
Corporation, of Santa Clara, California is the real party in interest. 

n. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences which will affect or be affected by the outcome 
of this appeal. 

in. STATUS OF CLAIMS 

Claims 1-20 are pending. Claims 1-20 are rejected in this application. Applicants hereby 
appeal the rejection of rejected Claims 1-20. 

IV. STATUS OF AMENDMENTS 

The claims are amended in accordance with the Response Amendment filed on January 13, 
2005, wherein Claim 1 was amended and Claim 21 was cancelled. The claim amendments and 
cancelled claim requested in the Response Amendment filed on January 13, 2005 regarding Claims 
1-20, as amended, and cancelled Claim 21 were entered. 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 

The pending claims relate to dynamically interacting with an Internet service using a 
communications proxy provided by a service provider matching a client-specified communication 
proxy type. As illustrated with reference to FIGS. 1, 2 and 5, Claim 1 recites a method including: 

registering an Internet service with a broker 102; 

transmitting metadata , to the broker 102, describing at least one 
communication proxy 106, including at least one supported protocol, a type, and a 
location of the conmiunication proxv 106; and 

accessing, by the communication proxy 106, a web server to provide the 
Internet service to a client 100 if the type of the communication proxy matches a 
communication proxy type specified by the client 100. (Emphasis added.) 

As illustrated in FIGS. 1 and 2 of Applicants' specification, the chent 100 interacts with the 
local communications proxy 106 at process block 212, while the communications proxy 105 
interacts with the service 104 on behalf of the client 100, as indicated at process block 214. 

FIGS. 1 and 5 illustrate registration with a broker 102 by a service 104, including metadata 
describing the service 104, any communications proxy 106 supporting various protocols, and any 
location of any proxy 106. At process block 502, the service 104 interacts with the client 100 by 
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interacting with the communication proxy 106, the communication proxy 106 being on the same 
node as the client 100. 

Accordingly, Claim 1 recites features performed by a service provider to register a service 
104 with a broker 102, such that access to the service 104 is provided via a conmiunication proxy 
106 provided by the service provider, assuming a type of the communications proxy 106 matches a 
communications proxy type specified by a client 100. 

Claims 6 and 17 cite analogous claim features. Claim 6 is representative. As illustrated 

with reference to FIGS. 1-3, Claim 6 recites features including: 

requesting a desired Internet service 104, by a client 100, to a broker 102, 
including a desired communication proxy type and, optionally, a desired application- 
level protocol; 

receiving metadata from the broker 102 regarding a conmiunication proxy 
106 having at least a matching communication proxy tvpe to the desired 
conmiunication proxy type; 

downloading th e communication proxy 106 from a location specified by the 
metadata : and 

interacting with a web server using the downloaded communication proxy 
106 to receive the desired Internet service 104. (Emphasis added.) 

Accordingly, as shown in process blocks 208-214 of FIG. 2, and process blocks 300-308 
of FIG. 3, the client 100 downloads a communications proxy 106 to the client node, which is 
provided by the service provider. As indicated by process blocks 212 and 214 of FIG. 2, the client 
100 interacts with the local communications proxy 106 at process block 212 and the 
communications proxy 106 interacts with the service 104 on behalf of the client 100 at process 
block 214. See, also, process block 308 of FIG. 3. 

As illustrated in FIGS. 1 and 4 of Applicants' specification, Claim 13 recites a method 
including the following claim features: 

receiving at least one Internet service registration 104 that includes metadata 
regarding at least one communication proxy 106; 

receiving a request to locate a client-desired Internet service having a client- 
specified communication proxy type : 

matching the request with the Internet service registration to identify a 
communications proxy 106 of the communication proxy type : and 

transmitting metadata to the client 100, the metadata including at least a 
location of the identified communication proxy 106. (Emphasis added.) 

As shown in process blocks 400-406 of FIG. 4 and described at ^0016, pg. 6 of 
Apphcants' specification, the Internet service registration received by a broker 102 includes 
metadata regarding at least one communication proxy 106. In addition, the client request received 
by the broker 102 for a client-desired Internet service includes a client-specified communication 
proxy type. As illustrated in FIG. 4, the broker 102 matches the client request with an Internet 
service registration to identify a communications proxy 106 of the communications proxy type and 
transmits metadata, including a location of the identified communication proxy 106. 
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As recited by dependent Claim 2, the communications proxy is downloaded from the 

location specified by the transmitted metadata to a node local to the client. As described with 

reference to Applicants' specification: 

In an embodiment, the client downloads the requested communication proxy 
and dynamically interacts, at runtime, with an Internet service using the requested 
communication proxy , the communication proxy being local to the client . In an 
embodiment of the invention, a client application is executing, and during runtime 
the client is interacting with die communications proxy. (See, pg. 3, f005 of 
Applicants' specification.) (Emphasis added.) 

As recited by dependent Claims 9 and 20, a client dynamically interacts with a web server 

using the downloaded communication proxy to receive the desired Internet service. As recited by 

Applicants' specification: 

By " dynamically interact" it is meant, in an embodiment of the invention, 
that the client has no prior knowledge of what is needed to interact with an Internet 
service . In an embodiment of the invention, the client is relieved from having to 
develop a remote communications code . (See, pg. 3, ^005 of Applicants' 
specification.) (Emphasis added.) 

Accordingly, as recited by dependent Claim 8, the web server is remotely accessed by the 
downloaded communication proxy according to the client. (See, supra .) 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The grounds of rejection involved in this appeal are as follows: 

Are Claims 1-20 unpatentable under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 
No. 6,594,700 issued to Graham ( "Graham '^)? 

VIL ARGUMENT 

A. Overview of the Cited References 

1. Overview of Graham Reference 

Graham describes a system and method for implementing a universal service broker 

interchange mechanism (USBIM). The USBIM taught by Graham is directed to a new form of 

networking that involves dynamic networks of consumer devices, which unpredictably join and 

leave the network. As indicated by Graham: 

A key aspect of making these networks easy to use is making them self- 
configuring , rendering them virtually transparent to the consumer. Service discovery 
protocols help make networks self-configuring, (col. 1, lines 24-28.) (Emphasis 
added.) 

As further indicated by Graham : 

The role of the service discovery protocol is to facilitate the service 
advertising and client lookup, and broker the service to the client, (col. 1, lines 44- 
46.) 
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As further described by Graham, conventional service discovery protocols do not 

allow clients operating under a first protocol to access services from a service provider operating 

according to a second protocol that is different than the first protocol. Accordingly, the teachings of 

Graham are directed to: 

[A] system and method for facilitating the different protocols to work in 
harmony between client and server providers . It would also be advantageous to 
provide a system and method to enhance the usability of services having their own 
unique protocols and to maximize the number of clients that can utilize them , (col. 
2, lines 7-13.) (Emphasis added.) 

Accordingly, the USBIM taught by Graham offers solutions to allow 

interoperability of devices and services that implement different service discovery protocols. In 

contrast to the prior art, Graham teaches service provider protocol adapter servlets and client 

protocol adapter servlets. As taught by Graham : 

Each protocol is associated with a different servlet that understands the 
details of the service advertising mechanism unique to that protocol. The unique 
protocol of the service provider is converted to a canonical representation of the 
service provider advertisemen t, (col. 6, lines 35-40.) (Emphasis added.) 

Accordingly, as taught by Graham : 

Each time a new service provider advertises a new service or updated service, 
service provider protocol adapter servlets 406 convert the service provider's unique 
protocol into a canonical representation and update internal registry 402 with the 
new service information . . . canonical representation is an important aspect of the 
present invention for providing interoperability among protocols , (col. 6, lines 42- 
57.) (Emphasis added.) 

As further taught by Graham : 

Client protocol adapter servlets 404, which function similarly to the service 
provider protocol adapter servlets 406, are componentized mechanisms based on 
servlets, that listen for client lookup requests . As with service provider protocol 
adapter servlets, a different client protocol adapter servlet handles the details of client 
lookup for each protocol . Client protocol adapter servlets convert the client request 
and the requesting client's protocol to a canonical representation of the request . 

In addition, client protocol adapter servlets 404 also search internal registry 
402 for the requested service advertisement in the index of service provider 
advertisements , and respond back to the requesting client with the results of the 
search using the chent's requested protocol , (col. 7, Unes 4-17.) (Emphasis added.) 

Accordingly, the use of the client protocol adapter servlets, service provider protocol 

adapter servlets, and canonical representation of service provider advertisements and client requests, 

obviate the need for requiring clients and service providers to have a matching protocol. In other 

words, as explicitly recited by Graham : 

In accordance with the preferred embodiment of the present invention, the 
protocols of the requester client and the service provider are unimportant . In the 
present invention, a client may have a protocol which is the same as or different from 
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that of the service provider because an interaction between the client and the service 
provider is brokered in a protocol-independent registrv 402. (col. 6, lines 12-18.) 
(Emphasis added.) 

Regarding the mechanism of client service provider interaction, Graham explicitly 

teaches that: 

Associated with the client lookup mechanism is the ability to broker the 
mechanism of client-service provider interaction , (col. 7, lines 17-19.) (Emphasis 
added.) 

Specifically, in an example provided by Graham regarding interaction between a 

UPnP protocol service and a Jini-based client, as is explicidy taught by Graham : 

[I]t is the responsibility of the client servlet to generate a marshalledObject 
(analogous to a network device driver) that has an implementation of the appropriate 
Java interface corresponding to LPR:. (col. 7, lines 22-26.) (Emphasis added.) 

In other words, as explicitly recited by Graham : 

[T]he client protocol adapter servlet brokers an interchange mechanism 
between the requester client and the service provider , (col. 7, lines 32-34.) 
(Emphasis added.) 

Referring again to the example provided by Graham: 

In the case of brokering a UpnP-based service to a Jini client, this is 
accomplished by providing a Java interface and implementation based on the 
Service-:Name: protocol associated with the service provider to the requesting client , 
(col. 7, Unes 34-38.) (Emphasis added.) 

Accordingly, as taught by Graham , the ability of the client protocol adapter servlet to 
broker an interchange mechanism between the requester client and the service provider renders the 
protocols of the requester client and the service provider unimportant, since the client protocol 
adapter servlet will broker the interchange mechanism between the client and service for the client to 
receive the service provided by the service provider. 

B. Rejection of Claims 1-5 as Anticipated by Graham 

The Examiner rejected all pending claims, including Claims 1-5 under 35 U.S.C. §102(e) as 
being anticipated by Graham. 

1. Errors of Law and Fact in the Rejection 

Applicants respectfully assert that the Examiner has failed to adequately set forth a 
prima facie rejection under 35 U.S.C. § 102(e). "Anticipation requires the presence in a single 
prior art reference disclosure of each and every element of the claimed invention, arranged as in the 
claims Lindemann Maschinenfabrik v. American Hoist & Derrick (" Lindemann "). 730 F,2d 
452, 1458 (Fed, Cin 7994j(emphasis added). Additionally, each and every element of the claim 
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must be exactly disclosed in the anticipatory reference. Titanium Metals Corp, of American v. 
Banner (" Banner Titanium "). 778 F 2d 775, 777 (Fed, Cir, 1985), 

Although the Examiner has rejected Claims 1-5 as anticipated by Graham, the 
Examiner fails to show that each and every element of the claimed subject matter is disclosed in 
Graham , as required to establish a prima facie case of anticipation under § 102(e). Id. 

According to the Examiner, Graham (col. 6, lines 1-49) teaches the transmitting 

metadata, to the broker, describing at least one communication proxy, including at least one 

supported protocol, a type, and a location of the conmiunication proxy, as recited by the claimed 

subject matter. (See, pg. 4, ^6 of Final Office Action mailed November 12, 2004.) Hov^ever, after 

careful review of the relevant portions of Graham cited by the Examiner, Applicants respectfully 

disagrees with the Examiner's contention. According to the Examiner: 

The information received from the service providers corresponds to 
transmitting metadata to broker and includes the type of communication proxy, that 
is adapter servlet required to convert the service provider's protocol to a canonical 
representation, e.g., XML or SGML. (Also see col. 6, line 50 - col. 9., line 30.) 
(See, pg. 5, first paragraph of Final Office Action mailed November 12, 2004.) 

Applicants respectfully submit that the Examiner has improperly equated the service 
provider protocol adapter servlets, as taught by Graham , with the communications proxy provided to 
a broker by a service provider, as recited by the claimed subject matter. In other words, Applicants 
respectfully submit that the Examiner is improperly equating the matching of client requested 
services with service providers providing the client requested service, which is referred to by 
Graham as the "chent lookup mechanism," (see, col. 7, lines 4-19) with the mechanism for 
interchange to provide client and service provider interaction once matching client and service 
providers have been found. 

Specifically, as recited by Graham and illustrated with reference to FIG. 5: 

The process begins by determining the service provider's unique protocol 
and using the appropriate service provider protocol adapter servlet for the 
advertisement in the unique protocol of the service provider (step 502). Next, a 
check is made to determine whether a service provider protocol adapter servlet is 
available for the protocol (step 504). (col. 8, Unes 7-13.) (Emphasis added.) 

Based on the cited passage above. Applicants respectfully submit that the USBIM 

taught by Graham provides the service provider protocol adapter servlet, which the Examiner has 

improperly equated with the conmiunications proxy, as recited by the claimed subject matter. 

However, in contrast to the Examiner's contention: 

The protocol adapter servlet is fundamental to the present invention , i f a 
servlet does not exist for this specific service protocol, the process ends , (col. 8, 
lines 18-20.) (Emphasis added.) 
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Hence, based on the cited passages above, the Examiner's contention that the service 
provider provides the service provider protocol adapter servlet (which the Examiner equates to the 
communications proxy as recited by the claimed subject matter) is directly contrary to the explicit 
teachings of Graham . As taught by Graham , the USBIM is responsible for providing the service 
provider protocol adapter servlets; and hence, if a service provider adapter protocol servlet does not 
exist for a service provider, the process ends. (See, Id.) 

Furthermore, according to the Examiner, Graham (col. 6, line 66 - col. 7, line 38) 

further teaches the accessing, by the communication proxy, a web server to provide the Internet 

service to a cUent if the communication proxy is compatible with the client requirement, as recited 

by the claimed subject matter. (See, pg. 5, first paragraph of Final Office Action mailed November 

12, 2004.) However, after careful review of the relevant portions of Graham cited by the Examiner, 

Apphcants respectfully disagrees with the Examiner's contention. According to the Examiner: 

The adapter servlet, which corresponds to the communication proxy, is 
compatible with the client environment and enables the client to request a service 
using the client's protocol from a service provider. (See, pp. 5-6 of Final Office 
Action mailed November 14, 2004.) 

Applicants respectfully submit that the Examiner has once again improperly equated 
the "client lookup mechanism" taught by Graham w ith the interaction mechanism between 
matching clients and service providers. Conversely, as recited by the claimed subject matter, the 
communications proxy provided by the service provider interacts with a web server to provide the 
Internet service to a client if the type of communication proxy provided by the service provider 
matches a communication proxy type specified by the client. 

Accordingly, Apphcants respectfully submit that although Graham teaches that the 
client protocol adapter servlet is responsible for the "client lookup mechanism", the client protocol 
adapter servlet is responsible for brokering the mechanism of client and service provider interaction; 
it is not responsible for providing the service to the client, as recited by the claimed subject matter; 
namely, as further taught by Graham, once the client lookup mechanism matches a client and a 
service provider: 

Associated with the client lookup mechanism is the ability to broker the 

mechanism of client-service provider interaction [T]he client protocol adapter 

servlet brokers an interchange mechanism between the requester client and the 
service provider , (col. 7, lines 17-35.) (Emphasis added.) 

Accordingly, Apphcants respectfully subnnit that the entire specification of Graham 

is restricted to teaching: 

Solutions to allow interoperability of devices and services that implement 
different service discovery protocols , (col. 2, lines 20-21.) 

To this end, Graham explicitly states that: 
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[T]he protocols of the requester client and the service provider client are 
unimportant . In the present invention, a client may have a protocol which is the 
same as or different from that of the service provider because interaction between the 
client and service provider is brokered in a protocol-independent registry 402. (col. 
6, lines 13-18.) (Emphasis added.) 

Hence, Applicants respectfully submit that the teachings of Graham fail to disclose a 
conmiunications proxy provided by a service provider, which interacts with a web server to provide 
a service to a client, as recited by the claimed subject matter. However, the case law is clear in 
establishing that each and every element of the claim must be exactly disclosed by the anticipatory 
reference. Id. 

Therefore, Applicants respectfully submit that the failure of Graham to disclose each 
and every element recited by the claimed subject matter prohibits the Examiner's use of Graham as 
an anticipatory reference to establish a prima facie case of anticipation of Claim 8. Id. Therefore, a 
prima facie case of anticipation of Claims 1-5 has not been established and the rejection of Clams 
1-5 is therefore erroneous. Id. 

2. Specific Limitations Not Described in the Prior Art 
Independent Claim 1 recites the following claim features, which are neither taught 
nor suggested by Graham or the references of record: 

registering an Internet service with a broker ; 

transmitting metadata , to the broker, describing at least one communication 
proxy , including at least one supported protocol, a type , and a location of the 
communication proxy : and 

accessing , by the communication proxy , a web server to provide the Internet 
service to a client if the type of the communication proxy matches a communication 
proxy type specified by the client . (Emphasis added.) 



3. Explanation Why Such Limitations Render the Claims Unanticipated by the 
Prior Art 

Applicants claim a method for dynamically interacting with an Internet service using 

a communications proxy specified by a service provider having a type that matches a 

communications proxy type requested by a client. As indicated by Applicants' specification and 

specifically, as illustrated with reference to FIGS. 1 and 2 of Applicants' specification: 

Service 104 registers with Broker 102 , transmits metadata describing any 
communication proxies , and provides attributes or keywords that describe the 
service as well as information pertaining to any communications proxies . . . Client 
100 registers with Broker 102 to request and locate a desired service that provides a 
client-requested type of communication proxy and protocol ... As shown in 
functional block 212, Client 100 interacts directly with local communication proxy 
106 to communicate with Service 104. By "local" it is meant that Client 100 and 
proxy 106 share the same node. The i nteraction between Client 100 and Service 
104 is simplified since Client 100 interacts only with the local component, the 
conmiunications proxy . . . Since Service 104 provides communication proxy 106, 
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communication proxy 106 includes the necessary logic to connect and communicate 
with Seryice 104 . {See, pg. 4, ^007 - pg. 5, ^0012 of Applicants' specification.) 
(Emphasis added.) 

Accordingly, as recited by Claim 1, once a client and seryice proyider are matched 

together (discoyery), a communications proxy proyided by the seryice proyider is used by the client 

to interact with the seryice if the communications proxy type matches a communications proxy type 

specified by the client. In other words, as described with reference to Applicants' specification: 

In an embodiment, the client downloads the requested communication proxy 
and dynamically interacts , at runtime, with an Internet seryice using the requested 
communication proxy, the communication proxy being local to the client . In an 
embodiment of the inyention, a client application is executing , and during runtime 
the client is interacting with the communications proxy . By "dynamically interact" 
it is meant, in an embodiment of the inyention, that the client has no prior knowledge 
of what is needed to interact with an Internet seryice . In an embodiment of the 
inyention, the client is relieyed from haying to deyelop a remote communications 
code . {See, pg. 3,^0005 of Applicants' specification.) (Emphasis added.) 

Conyersely, Graham teaches a system and method for implementing a uniyersal 
seryice broker interchange mechanism (USBIM). Graham is directed to a method including a 
seryice proyider protocol adapter serylet {see, col. 6, lines 28-40) and a client protocol adapter 
servlet {see, col. 7, lines 4-12), which respectiyely listen for seryice adyertisement and client lookup 
requests, which are conyerted into a canonical representation and stored within an internal registry. 
{See, col. 6, lines 50-65.) 

Once a client request is conyerted into a canonical representation of the request, the 
client protocol adapter serylet uses the canonical representation of the request to look-up the seryice 
required by the client ("client lookup mechanism"). Once a match has been found, the client 
protocol adapter serylet brokers the interchange mechanism of client and seryice proyider 
interaction. {See, col. 7, lines 13-19.) Accordingly, based on the cited passages aboye, Graham 
teaches seryice proyider protocol adapter serylets, client protocol adapter serylets and an intemal 
registry to proyide a client lookup mechanism between clients and seryice proyiders with different 
seryice discoyery protocols to proyide a desired service to the client. As is specifically stated by 
Graham : 

The present invention offers solutions to allow interoperability of devices 
and services that implement different service discovery protocols , (col. 2, lines 
19-21.) (Emphasis added.) 

Accordingly, since the USBIM allows interoperability of devices and services that 

implement different discovery protocols, Graham explicitly states that: 

[T]he protocols of the requester client and the service provider are 
unimportant . In the present invention, a client may have a protocol which is the 
same as or different from that of the service provider because an interaction between 
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the client and the service provider is brokered in a protocol-independent internal 
registry 402. (coL 6, lines 13-18.) (Emphasis added.) 

According to the Exanniner: 

The adapter servlet, which corresponds to the communications proxy, is 
compatible with the client environment and enables the client to request a service 
using the client's protocol from a service provider. {See, pg. 5, second paragraph of 
Final Office Action mailed November 12, 2004.) 

According to the Examiner, accessing by the communications proxy, a web server to 
provide the Internet service to a client if the communications proxy is compatible with the client, is 
taught at col. 6, line 66 to col. 7, line 38 of Graham {see, pg. 5, first paragraph of Final Office 
Action mailed November 12, 2004). However, after careful review of the cited passages indicated 
by the Examiner, Applicants respectfully disagree with the Examiner's contention. 

As explicitly described by Graham regarding the client protocol adapter servlet: 

Associated with the client lookup mechanism is the ability to broker the 
mechanism of client, service provider interaction , (col. 7, lines 17-19.) (Emphasis 
added.) 

As further described within Graham : 

In effect, the client protocol adapter servlet brokers an interchange 
mechanism between the requester client and the service provider . In the case of 
brokering a UpnP-based service to a Jini client, this is accomplished by providing a 
Java interface and implementation based on the Service- :Name: protocol associated 
with the service provider to the requesting client. (coL 7, lines 32-38.) (Emphasis 
added.) 

In other words, as specifically recited by Graham regarding the above example: 

[I]t is the responsibiUty of the client servlet to generate a marshalledObject 
(analogous to a network device driver) that has an implementation of the appropriate 
Java interface corresponding to LPR :. (col. 7, lines 21-27.) (Emphasis added.) 

Applicants respectfully submit that the above-cited passage is explicidy contrary and 
therefore does not disclose the recited features of Claim 1. Namely, as recited by Claim 1, the 
transmitting of metadata, which describes at least one communications proxy, a type, and a location 
of the communications proxy, is performed by the service provider. In other words, as recited by 
Claim 1, it is the duty of the service provider to provide the communications proxy, which will be 
used by the chent to interact with a web server to receive the service provided by the service 
provider. 

Conversely, Graham teaches that it is the responsibility of the client servlet to 
generate a marshalledObject to provide the mechanism of client and service provider interaction. 
{See, supra .) Hence, Applicants respectfully submit that although Graham teaches that a protocol of 
the client protocol adapter servlet must match a protocol of the chent and that a protocol of the 
service provider protocol adapter servlet must match a protocol of the service provider, the 
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interchange mechanism brokered by the cHent protocol adapter servlet is not required to match a 
communications proxy type specified by a client, as recited by Claim 1. 

Consequently, Applicants respectfully submit that the entire specification of Graham 
is devoid of any disclosure regarding a client-specified communications proxy type, which must be 
available from a service provider to match the client and service provider, as recited by Claim 1. 
Furthermore, Graham explicitly teaches that it is not the service provider that provides the 
communications proxy that a client will use to interact with a web server to receive the service 
provided by the service provider. As taught by Graham, the mechanism for interchange between the 
client and service provider is brokered by the client protocol adapter servlet. (See, supra .) 

Yet, in spite of the lack of any disclosure regarding an interchange mechanism 
between a client and a service provider using a communications protocol provided by a service 
provider that matches a client-specified communications proxy type, as recited by Claim 1, the 
Examiner incorrectly finds that Graham discloses each and every element of Claim 1. 

However, the case law is clear in establishing that each and every element of the 
claim must be exactly disclosed in the anticipatory reference. Id. Hence, Applicants respectfully 
submit that the failure of Graham to disclose each and every element recited by Claim 1 prohibits 
the Examiner's use of Graham as an anticipatory reference to establish a prima facie case of 
anticipation of Claim 1. Id. 

Therefore, Applicants respectfully submit that a prima facie case of anticipation of 
Claims 1-5 is not estabhshed and rejection of Claims 1-5 is erroneous and should be overturned. 
Accordingly, Applicants respectfully request that the § 102(e) rejection of Claims 1-5 be overturned. 

C. Rejection of Claims 6, 10-12 and 17-19 as Anticipated by Graham 
The Examiner rejected all pending claims, including Claims 6, 7, 10-12 and 17-19 under 35 
U.S.C. § 102(e) as being anticipated by Graham . 

1. Errors of Law and Fact in the Rejection 

The Examiner has made the same errors as previously described with respect to the 
rejection of Claims 1-5. Furthermore, although the Examiner has rejected Claims 6, 7, 10-12 and 
17-19 as anticipated by Graham, the Examiner fails to show that each and every element of the 
claimed subject matter is disclosed in Graham, as required to establish a prima facie case of 
anticipation. Id. 

According to the Examiner, Graham (col. 6, line 1 - col. 9, hne 40) discloses 
interacting with a web server using the downloaded communication proxy to receive the desired 
Internet service (see, pg. 8, ^ 2 of Final Office Action mailed November 12, 2004). However, after 
careful review of the relevant portions of Graham cited by the Examiner, Applicants respectfully 
disagree with the Examiner's contention. 
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As indicated by the Examiner at pg. 2, fl of Advisory Action mailed February 15, 

2005: 

In Graham, as analyzed in the previous Office Action, communication 
proxies correspond to client adapter servlets 404. 

Based on the cited passage above, Applicants respectfully submit that the Examiner 
has improperly equated client adapter servlets 404, as taught by Graham, with the downloaded 
communications proxy, as recited by Claims 6 and 17, which is used by the clients to interact with 
the web server to receive the desired Internet service. 

Although the Examiner is correct in stating that the client protocol adapter servlet 
has to be compatible with the client's protocol (see, supra of Advisory Action mailed February 15, 
2005), the client protocol adapter servlet referred to by the Examiner identifies a service provider 
that provides a service requested by the client. (See, col. 7, lines 4-17.) Graham refers to the 
matching of a client request with a requested service advertisement as the "client lookup 
mechanism." (See, col. 7, lines 4-12.) 

As explicitly described by Graham regarding the cHent protocol adapter servlet: 

Associated with the client lookup mechanism is the ability to broker the 
mechanism of client , service provider interaction , (col. 7, hnes 17-19.) (Emphasis 
added.) 

As further described within Graham : 

In effect, the client protocol adapter servlet brokers an interchange 
mechanism between the requester cUent and the service provider client , (col. 7, lines 
32-33.) (Emphasis added.) 

In other words, as specifically described by Graham, in an example regarding the 

brokering of an interchange mechanism between the requester chent and the service provider client: 

[I]t is the responsibility of the client servlet to generate a marshalledObject 
(analogous to a network device driver) that has an implementation of the appropriate 
Java interface corresponding to LPR:. (col. 7, hnes 21-27.) (Emphasis added.) 

Accordingly, based on the cited passages above. Applicants respectfully submit that 
although the client protocol adapter servlet is responsible for brokering the mechanism of 
interchange between the client and service provider, the client protocol adapter servlet is not 
downloaded from a location specified by metadata received from a broker and is thus not used for 
interacting with the web server to receive the desired Internet service, as recited by Claims 6 and 17. 

Hence, Applicants respectfully submit that the teachings of Graham are explicitly 
limited to a client protocol adapter servlet that performs a client lookup mechanism to match a client 
with the service provider that provides a matching service and subsequently brokers the interaction 
mechanism between the client and service provider. However, for at least the reasons indicated 
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above, the client protocol adapter servlet is neither downloaded nor used to access a web server to 
provide the desired Internet service to a client, as recited by the claimed subject matter. 

Hence, Applicants respectfully submit that the client protocol adapter servlet, as 
taught by Graham, fails to disclose each and every element of the claimed subject matter. However, 
the case law is clear in establishing that each and every element of the claim must be exactiy 
disclosed in the anticipatory reference. Id. Therefore, a prima facie case of anticipation of Claims 
6 and 17 is not estabhshed, and the rejection of Claims 6, 7, 10-12, 17, 18 and 20 is therefore 
erroneous. Id. 

2. Specific Limitations Not Described in the Prior Art 

Claims 6 and 17 recite analogous claim features. Claim 6 is representative. Claim 6 

recites: 

requesting a desired Internet service , by a client , to a broker , including a 
desired communication proxy type and, optionally, a desired application-level 
protocol; 

receiving metadata from the broker regarding a communication proxy having 
at least a matching communication proxv tvpe to the desired communication proxy 
type; 

downloading the communication proxy from a location specified by the 
metadata : and 

interacting with a web server using the downloaded communication proxy to 
receive the desired Intemet service . (Emphasis added.) 

3. Explanation Why Such Limitations Render the Claims Unanticipated bv the 
Prior Art 

Here, Graham fails to disclose the receipt of metadata from a broker regarding a 
conmiunications proxy matching a desired communications proxy type and downloading of the 
communications proxy to enable interaction with the web server to receive a desired Intemet service, 
as recited by Claims 6 and 17. In contrast, the teachings of Graham are limited to a service provider 
protocol adapter servlet for converting service advertisements from service providers into a 
canonical representation (see, col. 6, lines 42-57) and client adapter servlets to provide a client 
lookup mechanism to match a client request with a service provider according to the canonical 
representation within registry 402 (see, col. 7, hnes 4-17). 

Applicants respectfully submit that neither the client protocol adapter servlet nor the 
client protocol adapter servlet, as taught by Graham , are used to perform client service provider 
interaction, such as, for example, by downloading of the adapter servlet and interacting with the 
downloaded adapter servlet to receive a desired Intemet service from a web server, as recited by the 
claimed subject matter. 

Conversely, the teachings of Graham are explicitly limited to teaching that: 
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Associated with the cHent lookup mechanism is the ability to broker the 
mechanism of client and service provider interaction , (col. 7, lines 17-19.) 
(Emphasis added.) 

Applicants respectfully submit that the brokering of client and service provider 
interaction, as provided by the client protocol adapter servlet, does not disclose the downloading of a 
communications proxy with a communications proxy type from a location specified by metadata 
received from a broker and interacting with a web server using the downloaded communications 
proxy to receive the desired Internet service, as recited by Claims 6 and 17. 

However, the case law is clear in establishing that each and every element of the 
claim must be exactly disclosed by the anticipatory reference. Id. Therefore, Applicants 
respectfully submit that the failure of Graham to disclose each and every element recited by the 
claim prohibits the Examiner's use of Graham as an anticipatory reference to establish a prima 
facie case of anticipation of Claims 6 and 17. Id, 

Therefore, Applicants respectfully submits that a prima facie case of anticipation of 
Claims 6, 7, 10-12 and 17-19 is not established and the rejection of Claims 6, 7, 10-12 and 17-19 
are erroneous and should be overturned. Accordingly, Applicants respectfully request that the 
§102(e) rejection of Claims 6, 7, 10-12 and 17-19 be overturned. 

D. Rejection of Claims 13-16 as Anticipated by Graham 

The Examiner rejected all pending claims, including Claims 13-16 under 35 U.S.C. § 102(e) 
as being anticipated by Graham . 

1. Errors of Law and Fact in the Rejection 

The Examiner has made the same errors as previously described with respect to the 
rejection of Claims 6, 7, 10-12 and 17-19. Furthermore, although the Examiner has rejected Claims 
13-16 as anticipated by Graham, the Examiner fails to show that each and every element of the 
claimed subject matter is disclosed in Graham, as required to establish a prima facie case of 
anticipation. Id. 

According to the Examiner: 

Regarding Claims 13-20, their limitations are already covered in the Claims 
1-12 above and are therefore analyzed and rejected based on the same rationale as 
being anticipated by Graham. {See, pg. 9, ^1 of Final Office Action mailed 
November 12, 2004.) 

Applicants respectfully submit that the features recited by Claim 13 are distinct from 
the features recited by Claims 1-12, as stated by the Examiner. {See, supra .) Applicants 
respectfully submit that the Examiner has improperly equated the client lookup mechanism 
performed by client protocol adapter servlets taught by Graham with the recited features of the 
claimed subject matter; namely, matching of a request to locate a client-desired Internet service with 
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an Internet service registration having a client-specified conrununications proxy and transmitting 
metadata to the client regarding the communications proxy. 

Applicants respectfully submit that the matching of a service provider adapter servlet 
with the service provider, according to a protocol of the service provider, as illustrated in blocks 
502-506 of FIG. 5, as well as the matching of a client request protocol adapter servlet with a client 
according to a client request protocol, as shown in process blocks 702-706 of FIG. 7 of Graham, 
fail to disclose each of the recited features of the claimed subject matter. 

Specifically, as shown by process block 506, the receipt of the service provider 
protocol advertisement does not include metadata regarding at least one communications proxy. 
Furthermore, as illustrated by process block 706 of FIG, 7 of Graham, the receipt of the client 
request for service using the client request protocol does not disclose the receipt of a request to 
locate a client-desired Internet service having a client-specified communication proxy type. 

Hence, Applicants respectfully submit that the matching of a service provider with a 
service provider adapter servlet and the matching of a client with a client protocol adapter servlet, as 
taught by Graham, fail to disclose each and every feature of the claimed subject matter. However, 
the case law is clear in establishing that each and every element of the claim must be exactly 
disclosed in the anticipatory reference. Id. Therefore, a prima facie case of anticipation of Claims 
13-16 has not been established and the rejection of Claims 13-16 is therefore erroneous. Id. 

2. Specific Limitations Not Described in the Prior Art 
Claim 13 recites: 

receiving at least one Internet service registration that includes metadata 
regarding at least one conmiunication proxv : 

receiving a request to locate a client-desired Internet service having a client- 
specified conmiunication proxy type : 

matching the request with the Intemet service registration to identify a 
communications proxv of the communication proxy type : and 

transmitting metadata to the client , the metadata including at least a location 
of the identified communication proxy . (Emphasis added.) 

3. Explanation Why Such Limitations Render the Claims Unanticipated by the 
Prior Art 

Here, Graham fails to disclose the matching of a request to locate a client-desired 
Intemet service with an Intemet service having a client-specified communications proxy type and 
the transmitting of metadata to the client, including a location of the identified communications 
proxy, as recited by Claim 13. In contrast, Graham teaches a client protocol adapter servlet, which 
provides a client lookup mechanism to identify a service that matches a client-specified request. 

For at least the reasons indicated above, the client request, as illustrated in FIG. 7, 
process block 706 of Graham, fails to include a client-specified communications proxy type. 
Furthermore, the receipt of a service provider protocol advertisement, as illustrated in process block 
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506 of FIG. 5 of Graham, fails to disclose metadata regarding at least one communication proxy, as 
recited by Claim 13. 

Hence, although the client lookup mechanism provided by the client adapter servlet, 

as taught by Graham, matches an Internet service registration with a service matching a client 

request, as specifically taught by Graham : 

In accordance with a preferred embodiment of the present invention, the 
protocols of the requester client and the service provider are unimportant . In the 
present invention, a client may have a protocol which is the same as or different from 
that of the service provider because an interaction between the client and service 
provider is brokered in a protocol-independent registry 402. (col. 6, lines 12-18.) 
(Emphasis added.) 

As further described by Graham, the mechanism of client service provider 

interaction is performed by the client protocol adapter servlet: 

Associated with the client lookup mechanism is the ability to broker the 
mechanism of client service provider interaction . . . [T]he client protocol adapter 
servlet broker an interchange mechanism between the requester client and the service 
provider , (col. 7, lines 32-34.) (Emphasis added.) 

Accordingly, Applicants respectfully submit that the teachings of Graham are 

expressly limited to client protocol adapter servlets to perform a client lookup mechanism and the 

service provider adapter servlets to convert service advertisements received from service providers 

into a canonical representation within a registry to provide: 

[SJolutions to allow interoperabilitv of devices and service that implement 
different discovery protocols , (col. 2, lines 20-21.) 

Applicants respectfully submit that providing interoperability of devices and services 
that implement different service discovery protocols by using a client protocol adapter servlet, a 
service provider protocol adapter servlet and enhanced registry, as taught by Graham, fail to disclose 
each and every element of the claimed subject. However, the case law is clear in establishing that 
each and every element of the claim must be exactly disclosed by the anticipatory reference. Id. 

Consequently, Applicants respectfully submit that the failure of Graham to disclose 
each and every element recited by Claim 13 prohibits the Examiner's use of Graham as an 
anticipatory reference to establish a prima facie case of anticipation of Claim 13. Id. 

Therefore, Applicants respectfully submit that a prima facie case of anticipation of 
Claims 13-16 is not established and the rejection of Claims 13-16 is erroneous and should be 
overturned. Accordingly, Applicants respectfully request that the § 102(e) rejection of Claims 13-16 
be overturned. 
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E. Rejection of Claims 8. 9 and 20 as Anticipated by Graham 
The Examiner rejected all pending claims, including Claims 8, 9 and 20 under 35 U.S.C. 
§ 102(e) as being anticipated by Graham . 

1. Errors of Law and Fact in the Rejection 

The Examiner has made the same errors as previously described with respect to the 
rejection of Claims 6, 7, 10-12 and 17-19. Furthermore, although the Examiner has rejected Claims 
8, 9 and 20 as anticipated by Graham, the Examiner fails to show that each and every element of the 
claimed subject matter is disclosed in Graham , as required to establish a prima facie case of 
anticipation. Id. 

According to the Examiner, Graham (col. 9, lines 17-30) discloses that even though 
the client and the requested service on the service provider may be running at different protocols, the 
information is exchanged between the two dynamically. (See, pg. 8, third paragraph of Final Office 
Action mailed November 12, 2004.) However, after careful review of the relevant portions of 
Graham cited by the Examiner, Applicants respectfully disagree with the Examiner's contention. 

Applicants respectfully submit that the passage of Graham cited by the Examiner 

(col. 9, lines 17-30) describes the client lookup mechanism performed by the client protocol adapter 

servlet. As indicated by the cited passage: 

Using the canonical representation of the client-requested service , the 
internal registry may be searched for an advertisement for the requested service from 
a service provider . A check is made to determine whether the requested service is 
available in the index of the internal registry (step 710). (See, col. 9, Hnes 21-26.) 
(Emphasis added.) 

Applicants respectfully submit that the client lookup mechanism described in the 
above-recited passage fails to disclose that "even though the client and the requested service on the 
service provider may be running at different protocols, the information is exchanged between the 
two dynamically," as suggested by the Examiner. Hence, Applicants respectfully submit that 
performing of the client lookup mechanism by the client protocol adapter servlet, as taught by 
Graham , fails to disclose dynamically interacting with the web server using the downloaded 
communication proxy to receive the desired Internet service, as recited by the claimed subject 
matter. 

Consequently, the client lookup mechanism performed by the client protocol adapter 
servlet, as taught by Graham , fails to disclose the dynamic interaction with a web server using a 
downloaded communication proxy to receive a desired Internet service, as recited by the claimed 
subject matter. 

Hence, Applicants respectfully submit that the client lookup mechanism, as taught 
by Graham , fails to disclose each and every element of the claimed subject matter. However, the 
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case law is clear in establishing that each and every element of the claim must be exactly disclosed 
in the anticipatory reference. Id. Therefore, a prima facie case of anticipation of the claimed 
subject matter is not established, and the rejection of Claims 8, 9 and 20 is therefore erroneous. Id. 

2. Specific Limitations Not Described in the Prior Art 

Claims 8, 9 and 20 recite analogous claim features. Claim 9 is representative. Claim 
9 recites dynamically interacting. 

3. Explanation Why Such Limitations Render the Claims Unanticipated by the 
Prior Art 

Here, Graham fails to disclose dynamically interacting with a web server using a 

downloaded communication proxy to receive a desired Internet service, as recited by the claimed 

subject matter. As indicated by Applicants' specification: 

In an embodiment, the client downloads the requested communication proxy 
and dynamically interacts, at runtime, with an Internet service using the requested 
communication proxy , the communication proxy being local to the client . In an 
embodiment of the invention, a client application is executing, and during runtime 
the client is interacting with the communications proxy. By "dynamically interact" 
it is meant, in an embodiment of the invention, that the client has no prior knowledge 
of what is needed to interact with an Internet servic e. In an embodiment of the 
invention, the client is relieved from having to develop a remote communications 
code. (See, pg. 3, ^005 of Applicants' specification.) (Emphasis added.) 

Based on the cited passage above. Applicants respectfully submit that the recited 

claim features of the claimed subject matter are directed toward the interaction mechanism between a 

matching client and service in order for the client to receive the desired service from the service 

provider. Conversely, the teachings of Graham are expressly limited to providing: 

rSl olutions to allow interoperability of devices and services that implement 
different service discovery protocols , (col. 2, lines 20-2L) (Emphasis added.) 

To this end, Graham teaches a client protocol adapter servlet, which performs a client 
lookup mechanism to match a client request with a service provider advertisement. (See, col. 9, lines 
17-30.) Furthermore, Graham teaches the service provider protocol adapter servlet, which converts 
a service provider advertisement into a canonical representation; the client protocol adapter servlet 
and the service protocol adapter servlet enable interoperability between clients and services having 
different discovery protocols. (See, col. 6, Unes 42-57.) 

However, beyond the client lookup mechanism using canonical representations 
contained in the internal registry 402, as taught by Graham, Graham fails to disclose any teachings 
regarding the subsequent interaction between a matched client and service provider; and to this end, 
merely states that: 
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[A]ssociated with the client lookup mechanism is the ability to broker the 
mechanism of client-service provider interaction , (col. 7, lines 17-19.) (Emphasis 
added.) 

To this end, Graham teaches that: 

[T]he client protocol adapter servlet brokers an interchange mechanism 
between the requester client and the service provider, (col. 7, lines 32-34.) 

Accordingly, beyond mentioning that the client protocol adapter servlet brokers the 

interchange mechanism, the only further mention within Graham of this interchange mechanism is 

provided in an example, wherein Graham discloses: 

[I]t is the responsibility of the client servlet to generate a marshalledObject 
(analogous to a network de vice driver) that has an implementation of the appropriate 
Java interface corresponding to LPR :. (col. 7, lines 22-26.) (Emphasis added.) 
(Emphasis added.) 

The responsibility described by the client servlet to generate the marshalledObject is 

provided in conjunction with an example of client service provider interaction as follows: 

In the case of brokering a UpnP-based service to a Jini client, this is 
accomphshed by providing a Java interface and implementation based on the 
Service-:Name: protocol associated with the service provider to the requesting client , 
(col. 7, lines 34-38.) (Emphasis added.) 

Beyond the above-described example, Graham is silent and therefore fails to 
disclose any further action between the cUent and service provider. In spite of the lack of any 
disclosure regarding a dynamic interchange mechanism between a client and service provider using 
a communications protocol provided by a service provider that matches a client-specified 
communications proxy type, as recited by the claimed subject matter, the Examiner incorrectly finds 
that Graham discloses each and every element of Claims 8, 9 and 20. 

However, the case law is clear in establishing that each and every element must be 
disclosed in the anticipatory reference. Id. Hence, Applicants respectfully submit that the failure of 
Graham to disclose each and every element recited by Claims 8, 9 and 20 prohibits the Examiner's 
use of Graham as an anticipatory reference to establish a prima facie case of anticipation of Claims 
8, 9 and 20. Id. 

Therefore, Applicants respectfully submit that a prima facie case of anticipation of 
Claims 8, 9 and 20 is not established, and the rejection of Clams 8, 9 and 20 is erroneous and 
should be overturned. Accordingly, Applicants respectfully request that the § 102(e) rejection of 
Claims 8, 9 and 20 be overturned. 
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Vm. CONCLUSION AND RELIEF 

Based on the foregoing, Applicant requests that the Board overturn the rejection of all 
pending claims and hold that all of the claims of the present application are allowable. 

Respectfully submitted, 

BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN 



Dated: April ^,2005 
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IX. APPENDIX 



The claims involved in this Appeal are as follows: 

1 . A method comprising: 
registering an Internet service v^ith a broker; 

transmitting metadata, to the broker, describing at least one communication proxy, including 
at least one supported protocol, a type, and a location of the conmiunication proxy; and 

accessing, by the communication proxy, a web server to provide the Internet service to a 
client if the type of the conmiunication proxy matches a communication proxy type specified by the 
client. 

2. The method as in claim 1, further comprises: 

downloading the conmiunication proxy from the location to a node local to the client. 

3. The method as in claim 1, wherein the type of the communication proxy is one of 
Java, common language runtime (CLR), component object model (COM), and Win32 binaries. 

4. The method as in claim 1, wherein the at least one supported protocol of the 
communication proxy includes at least one of hypertext transfer protocol (HTTP), simple mail 
transfer protocol (SMTP), simple object access protocol (SOAP), secure sockets layer 
(SSUHTTPS), and secure HTTP (S-HTTP). 

5. The method as in claim 1, wherein the communication proxy is compatible with the 
client environment if the type of the communication proxy matches a communication proxy type 
specified by the client and the supported protocol of the communication proxy matches an 
application-level protocol specified by the client. 

6. A method comprising: 

requesting a desired Internet service, by a client, to a broker, including a desired 
communication proxy type and, optionally, a desired application-level protocol; 

receiving metadata from the broker regarding a communication proxy having at least a 
matching communication proxy type to the desired communication proxy type; 

downloading the communication proxy from a location specified by the metadata; and 

interacting with a web server using the downloaded communication proxy to receive the 
desired Internet service. 
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7. The method as in claim 6, wherein the communication proxy supports the desired 
application-level protocol. 

8. The method as in claim 6, wherein interacting further comprises: 

remotely accessing the web server by the downloaded communication proxy according to 
the client. 

9. The method as in claim 6, wherein interacting comprises: 
dynamic interacting. 

10. The method as in claim 6, wherein receiving metadata comprises: 

obtaining one of extensible markup language (XML), hyper text markup language (html), 
text file, and binary. 

1 1 . The method as in claim 6, wherein the desired communication proxy type is one of 
Java, common language runtime (CLR), component object model (COM), and Win32 binaries. 

12. The method as in claim 6, wherein the desired application-level protocol is one of 
hypertext transfer protocol (HTTP), simple mail transfer protocol (SMTP), simple object access 
protocol (SOAP), secure sockets layer (SSLTHTTPS), and secure HTTP (S-HTTP). 

13. A method comprising: 

receiving at least one Internet service registration that includes metadata regarding at least 
one communication proxy; 

receiving a request to locate a client-desired Internet service having a client-specified 
communication proxy type; 

matching the request with the Internet service registration to identify a communications 
proxy of the communication proxy type; and 

transmitting metadata to the client, the metadata including at least a location of the identified 
communication proxy. 

14. The method as in claim 13, wherein receiving said metadata comprises: 
obtaining descriptions of at least one supported protocol, a type, and a location of the 

communication proxy. 
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15. The method as in claim 13, wherein receiving said metadata comprises: 
obtaining one of extensible markup language (XML), hypertext markup language (html), 

text file, and binary. 

16. The method as in claim 14, wherein the communication proxy type is at least one of 
Java, common language runtime (CLR), component object model (COM), and Win32 binaries; and 
wherein a supported protocol of the communication proxy includes at least one of hypertext 
transfer protocol (HTTP), simple mail transfer protocol (SMTP), simple object access protocol 
(SOAP), secure sockets layer (SSL/HTTPS), and secure HTTP (S-HTTP). 

17. A machine readable medium having instructions which when executed by a machine 
cause said machine to perform operations comprising: 

requesting a desired Internet service, to a broker, including a desired communication proxy 

type; 

receiving metadata from the broker regarding a communication proxy having at least a 
matching communication proxy type to the desired communication proxy type; 

downloading the communication proxy from a location specified by the metadata; and 
interacting with a web server using the downloaded communication proxy to receive the 
desired Internet service. 

18. The machine readable medium as in claim 17, wherein the downloaded 
communication proxy supports a specified application-level protocol. 

19. The machine readable medium as in claim 17, wherein interacting is accomplished at 
runtime. 

20. The machine readable medium as in claim 17, wherein interacting comprises: 
dynamic interacting. 

21. (Cancelled) 
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